QRZ! Ham Radio 1

home *** CD-ROM | disk | FTP | other *** search

/ QRZ! Ham Radio 1 / QRZ Ham Radio Callsign Database - December 1993.iso / ucsd / a802.txt < prev next >

Wrap

Text File | 1988-10-26 | 34.1 KB | 723 lines

Fred R. Goldstein k1io 25 October 1988 Preface This is a draft description of a potential protocol for providing the Data Link Layer service to packet radio networks in the Amateur Radio Service. This draft presumes a familiarity with the AX.25 protocol adopted by the American Radio Relay League. Actual implementation is not suggested at this time. Intended audience: Amateur packet radio operators. This draft is leading towards an "ARFC". The A802 Metropolitan Area Network Protocol for Amateur Packet Radio I. Introduction Amateur Packet Radio has been practically synonymous with the AX.25 protocol since the early 1980s. While AX.25 has allowed packet operation to become quite popular, it has not proven to be fully sufficient for the task. Instead, it has created a minor industry in Terminal Node Controllers, which have isolated their users, and their computers, from the protocols themselves. A totally different protocol can take the place of AX.25, especially when used with more sophisticated upper layers such as TCP/IP. A candidate for such a protocol can be loosely based upon Local Area Networks which operate over shared cable; A802 takes such an approach. I.1. AX.25 is itself a misnomer AX.25 takes its name from Recommendation X.25 of the CCITT, the international consultative body that makes standards for telephone networks. X.25 itself is a definition for a standard interface into packet switched networks. It defines, in detail, two different layers of software. Layer 2 (or Level 2, in X.25's original terminology) is the Data Link layer, responsible for ensuring error- free transmission between adjacent entities. Layer 3 is the Network layer (originally the Packet layer) which operates across the boundaries of the network, establishing virtual circuits (connections) between users. (Layer 1, the Physical Link layer, simply transfers bits across a data connector, like the widely used RS-232 interface. Modem standards fall within the bounds of Layer 1, but are not part of X.25. Packet radio standards for Layer 1 are only partially covered within this document.) X.25's Data Link layer uses a protocol called LAP-B (Link Access Protocol - Balanced). This has been adapted, with much change, into AX.25. While X.25's network layer has been implemented in some connection-oriented networks, it is not part of AX.25. So the name AX.25 is really a misnomer; it is simply a much modified LAP-B. Like LAP-B, AX.25 is a member of the HDLC (High Level Data Link Control) family of protocols. HDLC frames (which is the correct term for packets at Layer 2) begin and end with a flag character, and allow data transparency by a bit insertion (stuffing) procedure. The last two bytes of the frame are the checksum, or cyclic redundancy check (CRC). Bit stuffing (and removal, on receive) is easily accomplished with specialized hardware, but next to impossible using standard personal computer modem interfaces. Hence the need for a TNC with its HDLC chip. While X.25 is widely used, it really has little in common with packet radio. For one thing, X.25 networks run over point to point wire lines. And LAP-B doesn't worry about addressing (there are only two stations on the wire, one at each end); lengthy address strings were added to create AX.25. II. The data link, the LAN and the MAN Packet radio operators know that their networks are not derived from X.25 wireline networks, as packet networks are often called Local Area Networks (LANs). This is not strictly accurate, since a LAN operates only within a building or campus, but packet radio MANs (metropolitan area networks) are still a lot more like LANs than like X.25 links. LAN protocols don't exactly follow the same layered model as X.25 or LAP-B, either: They don't strictly map into the traditional Layer 1 and Layer 2. The most widely used LAN standards are defined by IEEE committee 802, and include 802.3 (based on Ethernet), 802.4 (token bus) and 802.5 (token ring). Since token-passing has not been successfully demonstrated on packet radio, 802.3 comes closest to modeling radio. Indeed, the name "Ethernet" was coined by its inventors who noted that the coaxial cable was a broadcast medium not entirely unlike radio. Alas, it is also quite different from radio: Not only does it run much faster, but it is virtually lossless. II.1 LAN layers The lowest layer in a LAN, roughly within the physical link layer, is called the Physical Medium Dependent (PMD) layer. This, of course, differs greately between the different types of 802 LANs. The PMD layer is concerned with how bits are transmitted. The next layer up is the Medium Access Control (MAC) layer; this is where the stations on the LAN address each other, and determine when they can transmit. Finally, the Logical Link Control (LLC) layer provides the same types of services as a Data Link layer. There are two LLCs defined in IEEE 802.2; LLC1 provides a datagram service (like UI frames), while LLC2 provides a virtual circuit service (like I frames). LLC2 procedures (the types of frames and how they interact) are very close to LAP-B. II.2 The A802 protocols The LAN protocols found in IEEE 802 provide a model for packet radio. For the sake of discussion, these are herein called "A802"; the IEEE 802 protocols are merely an inspiration, but provide a model, just as X.25's Layer 2 provided a model for AX.25. A802 starts with a different premise than AX.25. It does not use HDLC, so there is no bit stuffing, and ordinary PC asynchronous communications hardware can be used. It also pays a bit less attention to terseness -- LAP-B headers cram a lot into a few bytes, but lack flexibility. As a further note, A802 can be run in either asynchronous or synchronous mode -- a low-end implementation can be sent using a standard asynchronous modem port, and monitored without special hardware. However, net throughput will be higher if synchronous transmission is used, and the two modes are not compatible. Thus any given transmission channel must be either synchronous or asynchronous or some stations will not be able to contact others. II.3 The A802 frame structure An A802 frame takes the following format: Frame { Sync_characters Literal "^V"s Mandatory MAC_header Structure Mandatory LLC_header Structure Mandatory Data String Optional Frame_checksum 2 bytes Mandatory } The sync_character is not part of the A802 frame itself, but is always transmitted at least twice before every frame. It has the literal decimal value of 22, or control-V; its purpose is to allow the receiving modem to establish synchronization. In synchronous mode, it establishes both byte and frame synchronization; in asynchronous mode, it only establishes frame sychronization. Note that HDLC protocols such as AX.25 can send any number of flag characters between frames; IEEE 802.3 precedes each frame with a stream of alternating 1 and 0 bits for synchronization. The A802 "header" consists of two separate sub-layers. The MAC sublayer provides addressing functions, while the LLC sublayer provides both connection-oriented and connectionless options. AX.25's basic functions are still provided, including support for digipeating. II.4 The MAC layer The Medium Access Control layer allows stations to address frames to one another. It is possible for a connection-oriented protocol to have a very small address field; instead of putting a full address (typically here, a call sign) in each frame, a data link control indicator (DLCI) refers to a previously-created connection. This has been done in the pioneering VADGC (Vancouver) packet radio protocols, and is done in both LAP-D (the ISDN follow-on to LAP-B) and X.25's Network Layer, which are connection-oriented. Like AX.25, however, A802 puts the source and destination addresses in every frame, allowing them to be handled as datagrams. A802 also supports digipeating. The fundamental components of a MAC header are the sender's and receiver's addresses. For example, Ethernet (and its follow-on IEEE 802.3) have a 48-bit address, so 96 bits of the MAC header are taken up by addressing. But digipeating makes life more complicated! Digipeating is more precisely referred to as source routed MAC relay: Source routed because the path is specified by the source of the packet, and MAC relay because the frame is simply relayed by the intermediate stations without looking at layers above MAC. (Source routing is supported in IEEE 802.5, the token ring LAN.) The MAC header can be described as MAC_header { Hop_pointer Integer (Mandatory) Destination_address Structure (Mandatory) Intermediate_address_1..7 Structure (Optional) Source_address Structure (Mandatory) Protocol_discriminator Alpha (Mandatory) } II.4.1 Addresses Each address field typically contains a call sign. In a simple two- station connection, the sender of the packet puts its call sign in the Source_address field and puts the other station's call in the Destination_address field. Secondary station IDs can be appended to the callsigns, as can portable identifiers, as the address is not constrained to 8 bytes (unlike AX.25 Version 2.0). II.4.2 Source routing Digipeating is accomodated via the Intermediate_addresses and the hop_pointer. The hop_pointer indicates which of the addresses (destination or intermediate) the frame is being directed to. In a two-station (no digipeater) packet, the Hop_pointer always has a value of 1. If there is one digipeater, then it begins with a value of 2; this means that the receiver recognizes the packet as its own when its own address is in the Intermediate_address_1 position. Likewise, if there are two digipeaters, the first digipeater increments the hop_pointer to 3 so that the second digipeater recognizes its address in the intermediate_address_2 position. And the last digipeater sets the hop_pointer to 1, the position of the destination address. A multicast or broadcast frame is sent with the hop_pointer set to 0. Thus the hop_pointer can have any value from 0 to 8. The hop_pointer is designed to reduce the processing load on receivers; they only have to listen to see if the pointed-to address is their own, and if it is not, then the frame can be ignore. The most common value will be 1; when this occurs, receiving stations may ignore subsequent addresses. (Conversely, when a frame has a hop_pointer value of 8, then every digipeater that hears it must wait until Intermediate_address_8 is sent. This is, of course, a degenerate case, as it is highly unlikely that a chain of 8 digipeaters will work! For identification purposes, the sender (as contrasted with the originator) of each transmitted frame is identified by determining the previous hop in the source routing chain. II.4.3 The protocol discriminator One final field in the MAC header is the protocol discriminator. This allows the upper layers to know what type of protocol the A802 frame is carrying in its data field. It should be noted that in the current Open Systems Interconnection Reference Model, protocol discriminators are taboo -- different protocols at the same node should be distinguished by different addresses. But AX.25 uses a protocol discriminator, Ethernet (pre-802) uses a protocol discriminator, and most TCP/IP users have grown to expect a protocol discriminator. So A802 has one too. (This does not rule out using distinctive addresses, if one chooses to do so.) The protocol discriminator is a single upper-case letter (A-Z). Tentatively values are as follows: Letter Protocol type I IP (as in TCP/IP) R ARP (Address Resolution Protocol) X X.25 Packet layer or OSI CONS (ISO 8208) O OSI Internet Protocol (ISO 8473) T Plain text Other values will be assigned as required. II.4.4. Parsing the MAC header Since some of the header fields are of variable length, they must be separated from one another. There are several techniques that could be used for this. LAP-B uses only fixed-length fields, while AX.25 uses fixed-length addresses with a bit set to indicate whether or not each has already been digipeated and another set to indicate which address is the last. Some protocols (notably those used in Open Systems Interconnection, the OSI program of the International Organization for Standardization) use a tag-length-value technique, which is very flexible but frequently takes at least 3 octets to do anything. A802 is a bit more like natural language -- it relies on taking each byte's values in context. Individual fields can only have certain values, so they end when a separator character, or one which cannot be part of that field, occurs. In A802, the MAC header is encoded using printable ASCII characters. The first octet of the MAC header is always a numeral, in the range 0-9 (although value 9 is presently reserved). This hop_pointer is followed by the destination_address. This can contain the characters A-Z, 0-9, plus the hyphen "-" and slash "/". The secondary station ID field, an AX.25 artifact whose value can be 0 through 15, can further be encoded using one ASCII character representing a hexadecimal digit, in the ranges 0-9 plus a-f, immediately following the call sign. Or a hyphen can be used, noting that K1IO-10 and K1IOa are two different addresses, though both represent the same ss_id. (Should these be equated? This requires further study.) Terse format (K1IO3) is recommended. Intermediate_address fields are optional, inserted only as required. Each one begins with the ASCII character "v", and then encodes call sign the same way as the destination_address. The source_address field, using the same encoding technique, is preceded by the ASCII character "<" (less than, or left-pointing angle bracket). This character is equivalent to the Morse code "DE". II.4.5 Examples of MAC header addressing A packet addressed to K1IO from 4X/WB2ZJQ1 without a digipeater: 1K1IO<4X/WB2ZJQ1 A packet addressed to FG0/K1IO/FS7-3 (K1IO operating portable on St. Martin using an FG0 authorization and the informal suffix FS7, SSID 3) from KA9Q8 via digipeaters WB2ZJQ and NP4XYZ would be initiated: 2FG0/K1IO/FS7-3vWB2ZJQvNP4XYZ<KA9Q8 This would be picked up by WB2ZJQ would would transmit: 3FG0/K1IO/FS7-3vWB2ZJQvNP4XYZ<KA9Q8 and it would finally be transmitted to FG0/K1IO/FS7-3 from NP4XYZ: 1FG0/K1IO/FS7-3vWB2ZJQvNP4XYZ<KA9Q8 It is possible to identify the sender (not originator, but the digipeater) of each packet, by following the process backwards! This is not particulaly human-friendly, but unambiguous to a computer. Note that the protocol discriminator is not shown above; it is the byte immediately preceding the LLC separator ":" (colon). II.5 The Logical Link Control header Logical Link Control provides the rest of the protocol's functions. A connection-oriented LLC (like IEEE 802's LLC2) provides an error- corrected, sequenced stream of frames -- a virtual circuit. AX.25's virtual circuit mode does the same thing; this is the usual way X.25 networks use LAP-B. A connectionless LLC (like IEEE 802's LLC1) does not try to make up for losses in the physical medium, but it is simpler and often adequate. This corresponds to UI frames in AX.25. Two LLCs are defined in A802. LLC-U is essentially similar to LLC1, providing an unsequenced datagram delivery service. LLC-C provides a connection-oriented (sequenced) service similar to that provided by LLC2. It does not, however, follow LLC2's specific procedures. The A802 LLC header also helps provide the frame integrity. It includes a frame length field and a header checksum. Since A802 does not follow the HDLC flag-delimiting technique or reserve any characters for "end of packet", it needs a way to indicate the end of a frame: The frame length field indicates how many bytes of data are in the frame, so the receiver simply counts bytes to determine the end of the frame. The header checksum decreases the chance that an error in the address or frame length causes the rest of the frame to be incorrectly framed, with the chance that an incorrect frame checksum is accepted. The LLC header takes this structure: LLC_header { Separator Lit. ":" Mandatory Control Alphabetic Mandatory Receive_sequence Alphabetic Optional Transmit_sequence Alphabetic Optional Length Integer Mandatory Header_Checksum Integer Mandatory } Note that the Control, Receive_sequence and Transmit_sequence fields will be described in Section III, below. All header fields up to and including Transmit_sequence are encoded in printable ASCII character; the remaining portion of the LLC header, and the rest of the frame, may have any arbitrary value. II.5.1 Length A802 is a byte-count protocol. The length field is not encoded in ASCII; it is a two-byte integer, with the high order byte followed by the low order byte. This allows large frames, though many or most frames will have a zero value in the high-order byte. The length field counts the number of bytes in the data field, following (not including) the header checksum. Some frames do not contain a data field. In such a case the length field remains, with a value of 0. II.5.2 Header Checksum The header checksum field is only intended to detect some number of header errors. It is a simple, one-byte value computed by adding up the binary value of every previous byte in the header plus the total number of bytes in the header (not including the checksum). If the checksum does not match when computed by the receiver, then the frame is discarded. The receiver also does not have confidence in the length field, and may lose frame synchronization (see below). II.5.3 The data field The whole point of this protocol is to exchange data; the header simply facilitates it. The data field in A802 begins six bytes after the separator (":") in I frames, four bytes after the separator in U frames, and five bytes after the separator in S, G and R frames. The maximum length of the data field is subject to negotiations by the two parties, and should be restrained in order not to "hog" a channel, but in a high-speed network can be as long as 8191 bytes. (This value is for further study.) On a 1200 bps half-duplex channel, however, a maximum of 256 bytes is recommended. There are no constraints on the contents of the data field, except that it must be an integral number of octets long. Segmentation of packets to accomodate different maximum data field lengths is for further study. II.5.4 The frame checksum At the end of every frame, following the data field (and not included within the length field) is the frame checksum. This is computed on the entire frame, beginning with the hop pointer and ending with the last byte before the frame checksum. The frame checksum uses the 16-bit CRC-CCITT cyclic redundancy checksum, identical with the one in AX.25. While computationally rather intensive, it will detect essentially all errors of fewer than sixteen bits and most longer errors. (Since A802 is intended for use in the absence of dedicated "TNC" hardware, which would normally implement CRC in hardware, use of a different checksum is for further study.) III. LLC procedures III.1 LLC-U operation: Connectionless The A802 connectionless mode of operation has a very simple LLC sublayer. The Control field has a value of "U", corresponding to Unnumbered Information (UI) frames in AX.25. All such frames stand alone. They do not have a receive_sequence or transmit_sequence. Thus the LLC-U header begins with the separator ":", followed immediately by the Length field and Checksum. If the frame checksum (as well as the header checksum) is valid, then the data is passed to the next layer up. If the checksum is invalid, then the data is not passed. III.2 LLC-C operation: Connection oriented A connection-oriented Logical Link Control provides sequenced, error-corrected packets. This isn't so simple: If a packet isn't acknowledged, it must be retransmitted by the sender. And since it might take some time for this to occur, the sender may wish to send more than one packet at a time. This is called a window, and is a feature of both AX.25, LAP-B and many higher layer protocols. A802's LLC-C defines three phases of data communications: Connection establishment, data exchange, and connection release. Connection establishment uses a three-way handshake (unlike AX.25's two-way handshake). Connection release uses a two-way handshake (more like AX.25). Each step can be described as a change in the connection state. These stages are initiated by values in the Control field. III.2.1 Connection establishment A802's connection establishment begins with the connection in a null state. The station which initiates the connection sends a frame with the Control field set to "A" ("ask for connection"). That station moves into the connection initiated state. The recipient station, if it chooses to accept the request, immediately responds with the Control field set to "B" ("begin to connect"). Neither A nor B frames may contain data. (A802 does not support "fast connect". You want fast, you use U frames!) The recipient, who sent the "B", is now in the connection pending state. If the receiver does not want to accept a connection request, then it responds not with a "B" but with a No Contact frame (Control value of "N"). The receiver stays in the null state. After receiving a "B" frame, the initiator sends a Connect frame (Control value of "C"). This step allows the recipient of the connect request to know that its "B" frame was received. Upon sending the C frame, the initiator moves into connected state; the receiver moves into connected state when it receives the C frame. As you can see, connection establishment is as simple as A-B-C! But of course, there are complications, mainly a number of necessary timers. When the initiator moves into the connection initiated state, it starts Timer A to await a response. If Timer A expires without any response, then the connection is assumed to have failed. It may re-initiate with another A frame. Once the recipient sends a B frame, it starts Timer B. If it does not receive a C frame before Timer B expires, then it retransmits the B frame once and restarts Timer B. If no C frame is received, then it assumes that the connection is lost and returns to the null state. If the C frame was lost, the originator will not know it until another B frame is received. It may have begun transmitting I frames in the meantime, but I frames must be acknowledged, and the receipt of a second B frame implies that the I frames have been rejected. Similarly, I frames received before a C frame are discarded by the receiver as being out of sequence. III.2.2 Data exchange Once a connected state is achieved, data exchange may begin. A802's connected mode makes use of sliding windows, not unlike AX.25. But in keeping with A802's alphabetic nature, it adopts a modulus of 26; letters are used to indicate the send and receive variables. The receive_sequence is encoded using lower-case ASCII letters; the transmit_sequence is encoded in upper case. During information exchange, the receive_sequence is transmitted in I, S and G frames; it has the downcased version of the next letter (a-z, wrapping z to a) after the last correctly-received frame's transmit_sequence. The transmit sequence (A-Z, wrapped) identifies each unique sequenced frame. Thus the first station to transmit information after connection establishment sends the I frame with sequence variables "IaA", inviting the other side to send its own frame A. If side X has received five frames frpm side Y and not transmitted any, then sends one frame, it sends "IeA". If X has a second frame to transmit right away, that frame is sequenced "IeB". Then, if Y sends its sixth frame, it sends IcF, which acknowledges X's frame B. In theory this allows up to (modulus - 1) 25 frames to be outstanding at once. This window size value k is typically much lower; in some half-duplex packet radio environments, it may need to be as low as 1, whence every frame must be acknowledged before another can be sent. Windows belong to the transmitting side only and need not be symmetrical; a station simply doesn't transmit more than k frames ahead of the last acknowledged frame. Every I frame must be acknowledged within the duration of the sender's timer I. If there is a relatively constant flow of data in both directions, then each side's I frames acknowledge the other side's. If, however, the recipient does not have data to send, then it still needs to acknowledge the received data before the sender's timer I expires. This is accomplished by sending a G (Go) frame with the appropriate receive sequence_value (the transmit_sequence value one after that of the last received I frame). Timer G determines how long the recipient waits before sending this G frame. If a frame is not acknowledged within timer I, then the station retransmits the frame. If a station retransmits the same frame r times without being acknowledged, then it assumes that the connection has been lost. It then transmits a D frame. III.2.3 Flow control Sometimes one side of a connection is incapable of handling any additional I frames. This may occur because of congestion further down the network, or because its receiver has filled (or anticipates imminently running out of) its buffers. When a station expects to be unable to handle additional traffic, it sends an S (Stop) frame. This contains a receive sequence value but not a transmit sequence. The sender of the S frame is now in a stopped state. Any I frame data received at this time is expected be discarded. (U frames may be accepted or rejected at the recipient's option.) Upon receipt of an S frame, the sender enters halted state. A station in halted state may not send further I frames, but may itself acknowledge receipt of I frames via S frames. A station in stopped state may, however, send I frames. Once the station is again able to receive traffic, it sends a G frame, moving from stopped to connected state. Its receive_sequence value should be the next one after that of the last I frame and match the one in the S frame which it cancels; however, at the receiver, value of the G frame takes precedence in case of mismatch. (This allows the receiver to accept additional I frames after sending an S frame, at its discression. S and G frames correspond loosely to RNR and RR frames in AX.25 and LAP-B.) III.2.4 Out of sequence packets If a valid frame is received whose transmit sequence is not exactly one more (modulo 26 from the A-Z sequence) than the last correctly received frame, then it is out of sequence. A802 is intended to operate only over simple point to point links, or over static digipeater chains, so sequence should always be preserved. Thus out of order packets imply that intervening packets have been lost. The recipient of an out of sequence frame should send an R frame with the receive_sequence value one greater than the correctly received frame's transmit_sequence. III.2.5 Connection release When either side of a connection wishes to release the connection, it sends a D (Disconnect request) frame. This contains a receive_sequence value one ahead of the last correctly received frame's transmit_sequence. It goes into the disconnect pending state. The recipient of a D frame immediately acknowledges it with an E (End) frame, which has no associated sequence variables. At this point both stations go into the disconnected mode. If the sender of the D frame does not receive an E frame within the time specified by timer A, then it should retransmit the D frame up to r times. III.3 Header checksum errors For every received frame, the header checksum should be computed and compared to the received value. If it is incorrect, then the frame is simply discarded. Since the number of bytes in the frame is part of the header checksum, the receiver must resynchronize. This is accomplished by waiting for two successive bytes with the decimal value of 22 (control-V) followed immediately by an ASCII representation of a numeric value, which could represent the first byte of a frame. This may or may not mark the beginning of a new frame. The receiver must then see if the potential new frame has a valid header checksum. Other heuristic means of determining frame breaks are for further study. Frame synchronization can typically be re-attained from the beginning of a new transmission, as noted from the Data Carrier Detect signal or squelch signal. III.4 Frame checksum errors If the frame checksum of any frame but an I frame is correct but the frame checksum is incorrect, then the receiver discards the frame. If the header checksum of an I frame is correct but the frame checksum is incorrect, then the receiver can have a fair degree of confidence that the frame in question comes from the sender identified in the MAC header, even if the data itself is valid. If the recipient of this corrupted data field has data to transmit, then it sends an I frame with the receive sequence value of the next anticipated frame following the last received valid frame. For example, if frame M was received correctly and a corrupt frame N was then received, the receiver's next outgoing I frame should have a receive sequence of "n". The transmitter then resumes from its frame N. If the recipient of the corrupted data does not have data to transmit, it should, without further waiting, send an R (Reject) frame with its receive_sequence value one after the last valid received frame's transmit_sequence value. (This will typically be the transmit sequence of the corrupt frame, but that may not be the case if other frames were lost.) III.5 Channel Access Procedures Packet radio does not exactly resemble any wireline medium. Different packet radio configurations, in turn, have different physical characteristics which impact procedures. The purpose of the channel access procedures is to guarantee that a shared channel does not reach a state where additional demand causes net throughput to decrease precipitously, a condition known as congestion collapse. This has been a significant problem in AX.25 networks. It is essentially impossible, however, in properly operated Ethernet networks. III.5.1 CSMA operation If it were not for the "hidden transmitter" problem, packet radio half-duplex operation would resemble carrier sense multiple access operation. CSMA operation can, however, be achieved when half- duplex packet stations operate through a repeater (a two-frequency repeater, not a digipeater). The repeater regenerates everyone's transmitted bits so that everyone else can hear them; this prevents any station from transmitting on top of another station unless they both start transmitting at almost exactly the same time. In CSMA operation, an A802 station with data to transmit first waits until the channel is free. It then waits for a random period of time t in the range m < t < s, where s is the slot time. Slot time is represented by TXdelay + Df: The sum of the transmitter keyup delay (TXdelay in some packet radio TNC operation) added to a constant Df. (Ideally, in a system where TXdelay is not long, Df represents the duration of a minimum-length frame; initially here, it should be at least equal to TXdelay, so that slot time is at least twice TXdelay. This value requries further study.) The minimum wait, m, is equal to TXdelay. On retransmissions, however, slot time increase exponentially: TXdelay + (Df*(2^t)), where t is the retransmission number beginning with 0 (for the first transmission) and ending with r. Thus each retransmission delay will take, on average, almost twice as long as the previous delay. But this is only the outer bound of a random function. III.5.2 CSMA/CD operation IEEE 802.3 and Ethernet use a contention technique called carrier sense multiple access / collision detection, or CSMA/CD. This is based on the concept that every transmitting station is simultaneously listening, so it knows if its signal was "clobbered" -- it compares the received signal to the transmitted one. (Ethernet, keeping it simple, uses a current source into a fixed 50 ohm load. If the voltage goes above the transmitter's own output voltage -- i.e., it detects 6 v when it transmits at 3 v -- then it knows a collision has occurred. This obviously does not work when an antenna is used.) Stations must listen before they transmit. However, it is possible that two stations choose to transmit at almost exactly the same time. This causes a collision. Since the station is listening, though, it does not complete sending the packet. It stops transmitting and waits a random interval within (2^n * slot_time), where n is the retransmission count. This leads to a conclusion that, given sufficient received signal strengths (i.e., low bit error rate exclusive of collision), LLC-U operation is appropriate for CSMA/CD operation, while LLC-C operation is most desirable for CSMA operation. If CSMA operation is used, then a collision-caused error can only be recovered by an end-to-end layer, either operating across a digipeater chain or at a higher layer. From a practical perspective, CSMA/CD operation requires all stations to operate using full-duplex radios, listening to a repeater output even as they transmit to the input. Hence very little amateur packet radio operation is true CSMA/CD. III.5.3 Single-frequency operation With a single frequency and no repeater, even true CSMA is not possible. Stations must still listen before transmitting, but the sender might not hear a third station that blocks its transmission from reaching the receiver. This is the "hidden transmitter" problem. Single-frequency operation thus has a lower maximum channel throughput than true CSMA operation, though higher than Aloha operation, in which stations transmit without listening. The same procedures as used in CSMA operation should be used in single-frequency operation. However, it may be necessary to use longer initial slot times. This is for further study.